Types of deployment

Important: This guide does not include any details about the Aucerna Cloud (hosted) deployment of Planning Space (see Deployment infrastructure overview). The following information is only about on-premises deployment.

Architectural design decisions for on-premises deployment mainly fall into server-side or client-side issues. The main elements of a Planning Space deployment are shown in the following diagram.


Schematic diagram of a Planning Space (and CX Suite) deployment. The elements shown in grey (SMTP Server, Application Provisioning servers) are optional. Client sites may be all local, or all remote, or a combination.

It is important to deploy Planning Space at the correct size initially, based on good estimates of initial and future capacity (that is, the number of server machines, and the CPU, RAM and disk resources allocated to each machine). Experience has shown that making changes in production deployments is typically a very slow and time-consuming process.

Server-side architecture

IPS server is deployed in a data center with the following resources:

  • one or more dedicated IPS Server machines (multiple machines are called a 'cluster');
  • a load balancer to interface with a cluster of IPS Server machines;
  • access to a Microsoft SQL Server service to provision and run databases (for version 16.5 Update 17 and later Azure SQL can be used to run the IPS Common and Tenant databases);
  • a file share (Cluster Shared Temp folder) for temporary storage and inter-process communication;
  • (optional) access to an SMTP server to provide automated email-based communication with users;
  • (optional) application provisioning service (such as Citrix) for provisioning of Planning Space services to remote client machines;
  • a data center LAN to inter-connect all of the servers and the file share (latency between servers must be 1 ms or lower);
  • a firewall at the perimeter of the entire server deployment, to control external communication with client user sites.

The IPS server-side deployment is quite simple to implement, but careful planning is recommended to determine the initial processing and storage resources required, and the planned scaling of resources for future growth in usage.

When users' immediate processing requests exceed the system capacity, requests are automatically queued for later completion. A design trade-off for system capacity needs to be decided between delivering immediate responses to user's requests, and forcing users to wait for completion of their requests (or require them to use batch processing of jobs). The level of use of Planning Space applications tends to be strongly cyclical through the year (as it is tied to annual business planning cycles) and it may be desirable to design a Planning Space deployment so that some level of 'batch' processing is going to occur at peak usage periods, or alternatively to plan for the use of temporary 'burst' compute resources at peak periods.

As the use of Planning Space develops within a company, the volume of available historical data grows and this means that the amounts of data which need to be stored and transferred to satisfy user requests tend to grow over time.

Single or clustered IPS Server

IPS Server is inherently-designed to operate in a clustered architecture with multiple server machines, which requires (at minimum) only a basic load balancer to mediate the client-server traffic.

A cluster is relatively simple to implement for an initial deployment (or to switch from a single server machine at a later date). The key design considerations for using a cluster are:

  • Resilience: 2 or 3 server machines are recommended to ensure continuous availability of the IPS Server.
  • Scalability: one server machine can handle up to 200 concurrent user sessions, however the number of batch jobs also needs to be considered, and the level of use of the Economics application which is the most resource-hungry module in Planning Space.

'SSL offloading' is an optional IPS Server configuration, where the SSL encryption and decryption are handled by the load balancer server, and traffic between the load balancer and the IPS Server machines uses unencrypted HTTP communication.

Multi-tenanted IPS server

Tenants in the IPS Server allow for the creation of independent (isolated) deployments which are separately-managed and store data and user profiles in separate databases.

IPS Server is tenanted by design, and must be initially configured with at least one tenant.

Multiple tenants are recommended for the following purposes:

  • to have a UAT (or 'sandbox') environment for software testing that is independent from the production environment(s);
  • to have different production environments that comply with the security and access requirements of different regulatory regimes;
  • to create archive versions of a production environment;
  • to optimize database size for good application performance.

Client-side architecture: ClickOnce or Installer-based deployment

Planning Space and CX Suite are based on client-server architectures and the main architectural design choice to be made is between:

  • ClickOnce (thick client) deployment: Client user machines connect directly to the IPS Server (and directly to SQL Server for CX Suite) using application programs based on Microsoft ClickOnce technology; this is also referred to as 'bootstrap deployment';
  • Installer-based deployment: Client user machines connect to an application provisioning service (Citrix being the most-commonly used) in the same data center as the IPS Server, which manages the connections to the IPS Server and SQL Server. The Planning Space (and CX Suite) client applications are installed and run on an application provisioning server, while the user's machine streams a session that is provided by the application provisioning service.

The choice depends mainly on the network latency and total available bandwidth between the client and server locations, particularly in the case of CX Suite. The key difference between CX Suite and Planning Space in terms of database operations is that CX Suite requires a direct, low latency connection between every user client and the database server, while Planning Space uses IPS Server as a database operation mediator/aggregator which allows for efficient use of the available client-server network bandwidth.

The network requirements for ClickOnce-based deployment are:

  • CX Suite: latency between client machine and SQL Server less than 5 ms; bandwidth of at least 100 MBits per second;
  • Planning Space: latency between client machine and IPS Server less than 150 ms, bandwidth of 10 MBits per second.

When looking at network capacities you will need to consider growth requirements for your Planning Space deployment, which will tend to grow not only in terms of number of concurrent users but also in terms of the quantities of data being transported for each concurrent user.


Schematic diagram showing Planning Space (and CX Suite) client-side architecture and network traffic, for a cluster of IPS Servers (two machines). 'ClickOnce client' users communicate with the IPS Servers via a load balancer. 'Installer-based client' users do not communicate directly with the IPS Servers; the Planning Space (or CX Suite) 'service' is provisioned by the Application Provisioning servers.

Multiple IPS server deployments

Multiple deployments of Planning Space can be created, where the IPS servers and databases operate independently.

Multiple deployments are most commonly used in the case of operational regimes where data pertaining to one country are required to be stored and processed within the borders of the same country.

However, centralized pool licensing for Planning Space and CX Suite applications can be implemented for any number of deployments by using the license server proxy option in the IPS Manager for each deployment. Hence one IPS server can provide shared global licensing services to a group of deployments, which may be more efficient for the overall use of licenses.